\chapter{Capacitat d’adaptació de la solució proposada}

\section{Introducció}
Una de les parts més curioses del projecte és l’adaptació de la interfície
d’usuari. Actualment el component client és capaç d’adaptar la interfície
d’usuari dinàmicament i automàticament, en qualsevol moment que li arribi un
canvi. El sistema, però, ha estat limitat ja que aplicar canvis en qualsevol moment podria
perjudicar l’ús de la Interfície d'Usuari (IU) ja que despistaria a l’usuari. És
per això que la proposta d’adaptació es mostra únicament cada cop que s’inicia l’aplicació. S’ha
vist en capítols anteriors que aquesta proposta d'adaptació es genera al
component servidor en el motor d’inferència, mitjançant l’aplicació de regles
prèviament definides pels administradors del sistema. Aquestes regles provoquen una proposta, formada
per una sèrie de canvis a la interfície d’usuari. Aquest capítol es centra en
explicar quins són els canvis que les regles poden proposar, així com quines
limitacions i peculiaritats tenen.

\section{Homogeneïtat vers les llibreries gràfiques}
Aquest és potser el concepte més important del capítol. S’ha fet un esforç per a
que la definició de canvis sobre la IU, fós completament
independent del component client. Això es pot veure com un inconvenient ja que limita el ventall
de possibles canvis als especificats pel protocol propi, que serà definit
després. No obstant esdevé en un gran avantatge quant a la definició de regles,
ja que, a banda de simplificar la seva escriptura, les regles poden ser
reutilitzables. De fet una regla pot ser aplicada sense necessitat de
modificar-la ni el més mínim a qualsevol aplicació objectiu i client,
independentment de si es tracta d’un client J2ME, J2SE, o algun altre soportat
en un futur. Tampoc influeix, doncs, si l’aplicació està construída amb Swing,
AWT, SWT, LCDUI, LWUIT,  ó qualsevol altra llibreria que sigui suportada en un
futur al component client.

\section{Adaptacions permeses pel protocol}
Actualment el protocol suporta els següents canvis a qualsevol element de la
interfície gràfica:\\

\begin{itemize}
  \item Vertical size
  \item Horizontal size
  \item Background color
  \item Foreground color
  \item Font size
  \item Font style
  \item Font type
\end{itemize}

El nombre de canvis suportats pot crèixer en un futur, simplement expandint el
protocol. Cal advertir també que, de la llista de canvis possibles, només podran
esdevenir efectius aquells que la llibreria gràfica suporti. Es recorda doncs
que apareixen tres limitacions quant a aplicació de possibles canvis:\\

\begin{itemize}
  \item La limitació que imposa el protocol, és a dir, que el canvi que es vol proposar
no aparegui a la llista del paràgraf anterior
  \item La limitació de la llibreria gràfica, és a dir, que el canvi que es vol
proposar no sigui suportat per la llibreria gràfica. Per saber més sobre
aquestes limitacions consulti el capítol següent
  \item La limitació de l’UIAdapter, és a dir, la limitació de la implementació
concreta per una llibreria gràfica de la classe que s’encarrega d’aplicar els canvis al
component client. Fòra el cas d’un canvi que estigui especificat al protocol,
sigui viable fer-lo amb la llibreria gràfica utilitzada per l’aplicació, però el
component client sigui incapaç de transmetre aquesta informació a la llibreria
gràfica
\end{itemize}

\section{Especificació del protocol de comunicació servidor-client}
Els canvis són enviats via XML al component client. El XML ha de tindre el
format especificat aquí per a que el component client el pugui parsejar i
entendre correctament.\\

El document ha de tindre com a element arrel \verb+<PROPOSAL_SET>+.
Dins l’element arrel es poden trobar tantes propostes de canvi com es vulguin.
Cada proposta representa un canvi lógic que s’aplicarà a la interfície d’usuari.
Per exemple, es pot voler canviar el color de fons de tots els elements de tipus
JLabel a blau, això representa un canvi lògic, que després podrà esdevenir en
més d’un canvi físic a la IU, ja que pot haver més d’un JLabel, i tots
canviaran el seu color de fons a blau. L’element XML que representa una proposta és el
següent: \verb+<PROPOSAL>+.\\
Una proposta ha de contenir exactament dos elements:
\verb+<CONSTRAINTS>+ i \verb+<CHANGES>+. El primer especificarà a quins elements
de la interfície d’usuari s’aplicaran els canvis. Per tal de determinar exactament a
quins \verb+<CONSTRAINTS>+ podrà tindre un o més elements \verb+<WIDGET>+.\\
L’element \verb+<WIDGET>+ no representa un element de la interfície d’usuari
sinò una regla per seleccionar un nombre d’ells. Així, si es té, per exemple, un
element \verb+<WIDGET>+ amb l’element \verb+<TYPE>+ especificant JLabel, només
els elements de la interfície que siguin del tipus JLabel rebran els canvis
proposats en aquest \verb+<PROPOSAL>+. Si s’especifiquen varies propietats dins
l’element \verb+<WIDGET>+ els canvis només s’aplicaran als elements de la
interfície d’usuari que cumpleixin TOTS els requisits. Si s’afegeix més d’un
element \verb+<WIDGET>+ dins \verb+<CONSTRAINTS>+ els canvis s’aplicaran als
elements de la IU que cumpleixin totes les propietats especificades a
qualsevol dels \verb+<WIDGET>+.\\

Simplificant, les propietats definides dins \verb+<WIDGET>+ actuen amb lògica
AND mentre que el conjunt de \verb+<WIDGET>+ actua amb la lògica OR.\\

Suposem que es vol canviar el color de la lletra a blanc de tots els
\verb+<WIDGET>+ que siguin del tipus \verb+JLabel+ i tinguin un color de fons
blau. Dins l'element \verb+<CONSTRAINTS>+ hi aniria el següent:\\
\verb+<WIDGET>+\\
\verb+<TYPE>JLabel</TYPE>+\\
\verb+<BACKGROUND_COLOR>0,0,255</BACKGROUND_COLOR>+\\
\verb+</WIDGET>+
\\

En canvi si es vulgués aplicar aquest canvi només als elements de la interfície
que tinguessin color blau o bé que fóssin del tipus \verb+JLabel+ es definirien
les restriccions de la següent forma:\\
\verb+<WIDGET>+\\
\verb+<TYPE>JLabel</TYPE>+\\
\verb+</WIDGET>+\\
\verb+<WIDGET>+\\
\verb+<BACKGROUND_COLOR>0,0,255</BACKGROUND_COLOR>+\\
\verb+</WIDGET>+
\\
D'aquesta manera els canvis s'aplicarien a molts més elements que no pas en
l'exemple anterior, ja que no caldria que les dues restriccions fóssin certes
per a cada widget a l'hora.\\

Finalment, el element del document on estan especificats els canvis és
\verb+<CHANGES>+. Aquest element pot contenir només un element \verb+<WIDGET>+,
les propietats del qual definiran els canvis a realitzar.\\

I quines propietats permet l’element \verb+<WIDGET>+? Es poden utilitzar els
següents elements dins el tag \verb+<WIDGET>+:\\
\begin{itemize}
  \item \verb+<VSIZE>+ Representa el tamany vertical d’un element
  \item \verb+<HSIZE>+ Representa el tamany horitzontal d’un element
  \item \verb+<BACKGROUND_COLOR>+ Representa el color de fons d’un element
  \item \verb+<FOREGROUND_COLOR>+ Representa el color en primer pla d’un element
  (per exemple, el color del que es renderitzaran les lletres, etc)
  \item \verb+<FONT>+ Representa una font de lletra, la qual pot tindre
  qualsevol de les propietats definides al següent paràgraf

\end{itemize}

L’element \verb+<FONT>+ pot tenir qualsevol dels elements següents:\\
\begin{itemize}
  \item \verb+<SIZE>+ Representa el tamany de la font
  \item \verb+<STYLE>+ Representa l’estil de la font. Els estils reconeguts actualment
són:
	\begin{itemize}
	  \item BOLD (Negreta)
	  \item ITALIC (Cursiva)
	  \item BOLDANDITALIC (Negreta i cursiva a l’hora)
	  \item NONE (Estil normal, ni negreta ni cursiva) 
	\end{itemize}
	
  \item \verb+<TYPE>+ Representa la familia de la font, que pot ser qualsevol de les
famílies disponibles al sistema client
\end{itemize}

Cal remarcar que els colors han de ser especificats a l’estil r,g,b (RGB, Red
Green Blue), amb una precisió de 8 bits per canal. Això dóna una profunditat de
color total de 24 bits, i el valor de cada canal va de 0 a 255, éssent 0 la
intensitat mínima d’un canal i 255 la intensitat màxima permesa. Per qualsevol
dubte en el format en que s'han d'especificar les dades es recomana consultar
els logs generats pel component client, ja que el format d’entrada del component
client és similar al format de sortida. Per qualsevol altre dubte en la formació de les
propostes consultar el DTD (Document Type Definition, un document on
s'especifica un cas concret del meta-lleguatge XML) proporcionat al final del
capítol.\\

Quant a la família de la font, s’ha d’aclarir que obviament la font (com a
recurs) no és proporcionada per la proposta de canvi, sinò només el nom o
referència a la la mateixa. Això implica que es pot proposar un canvi
especificant una font que el client no tingui. Si és aquest el cas el canvi no
es pot aplicar i el la font serà renderitzada com si no s’hagués especificat un
canvi de familia. Per saber quines fonts estan permeses a un sistema concret i
quina format ha de tindre la seva referència hom pot consultar els logs
proporcionats pel component client.\\

Tot completant aquesta informació i com s'ha mencionat en el capítol anterior a
continuació es mostra aquest format de comunicació en la seva versió DTD:
 \begin{lstlisting}
 <!DOCTYPE PROPOSAL_SET [
<!ELEMENT PROPOSAL_SET (PROPOSAL+)>
	<!ELEMENT PROPOSAL (CONSTRAINTS,CHANGES)>
		<!ELEMENT CONSTRAINTS (WIDGET*)>

<!ELEMENT WIDGET (HSIZE,VSIZE,FOREGROUND_COLOR,BACKGROUND_COLOR,TYPE,FONT)>
		<!ATTLIST WIDGET	ID	ID	#REQUIRED>
<!ELEMENT HSIZE (#PCDATA)>
<!ELEMENT VSIZE (#PCDATA)>
<!ELEMENT FOREGROUND_COLOR (#PCDATA)>
<!ELEMENT BACKGROUND_COLOR (#PCDATA)>
<!ELEMENT TYPE (#PCDATA)>
<!ELEMENT FONT (TYPE,SIZE,STYLE)>
<!ELEMENT TYPE (#PCDATA)>
<!ELEMENT SIZE (#PCDATA)>
<!ELEMENT STYLE (#PCDATA)>

		<!ELEMENT CHANGES (WIDGET)>

<!ELEMENT WIDGET (HSIZE,VSIZE,FOREGROUND_COLOR,BACKGROUND_COLOR,TYPE,FONT)>
		<!ATTLIST WIDGET	ID	ID	#REQUIRED>
<!ELEMENT HSIZE (#PCDATA)>
<!ELEMENT VSIZE (#PCDATA)>
<!ELEMENT FOREGROUND_COLOR (#PCDATA)>
<!ELEMENT BACKGROUND_COLOR (#PCDATA)>
<!ELEMENT TYPE (#PCDATA)>
<!ELEMENT FONT (TYPE,SIZE,STYLE)>
<!ELEMENT TYPE (#PCDATA)>
<!ELEMENT SIZE (#PCDATA)>
<!ELEMENT STYLE (#PCDATA)>
 \end{lstlisting}
